I'm very much in favour of having an Editor Window option and I'd agree with the concern for multiple registrations. I'll have a look and a think about ways to approach it. I'd lean towards either options within the Game Debugger itself or allowing it to route the information to multiple sources.

For the multiple entries that looks less like duplicate entries and instead it showing info for AIs other than the focussed one. Which is intentional but does look confusing with it being shown first and at the same level. I'll see what can be done to improve that as part of the Editor Window changes.

Update comment to mention that, in this prototype PR the agents are listed separately - so this may be a handy way to view everyone in the scene as well as an alternative way to navigate to the debug information more directly.

Thinking about this a bit more, an added-bonus could be that, when selecting an agent in this new list, the corresponding GameObject in the hierarchy is selected (the side effect of highlighting that selected agent in the SceneView would be super nice).

I guess that having a tickbox [somewhere in the editor window] to enable/disable this hierarchy-auto-selection behaviour, is a usability feature that's probably going to be needed.

I was just quickly trying to add a small update to the code in this PR, to include something that looks something along the lines of this non-working pseudocode (complete hack, missing any safety check etc etc):

 // event code that is called when clicking on item in left-hand panel
  private void OnAISourceSelectionChange(IEnumerable<object> selectedItems)
  {
      var selectedObject = (GoapBrainWrapper)selectedItems.First();
      Selection.activeGameObject = selectedObject.gameobject;
      RefreshUI();
  }

However, I quickly tripped up on a scoping problem:

In the case of the demo, List<IDebuggableObject> Sources returns a HybridGOAPExample.GOAPBrainWrapper component/object. This doesn't exist within CommonCore as GOAPBrainWrapper is a user-implementation concern.

BTW, zero expectation on my part to merge this PR, it's just a convenient way to articulate an idea :-D

I should be able to add support to IDebuggableObject to retrieve (possibly optionally) an associated MonoBehaviour/GameObject and that might work to get around the access restriction. And yep I want to keep the PR around as a reminder and reference point till I figure out which way to head with it. That'll probably be post the inclusion of the Behaviour Tree system just in case that modifies the debugger further.

It's not in the repo yet (it'll be part of the behaviour tree system) but I've setup the groundwork for this. I've split out the gameplay debugger into a core that tracks sources and generates the data and the display side. Multiple displays at the same time are supported and kept in sync. So it'll be much easier to add the editor window and support either or both :)

Cool.
I continued to modify that version I was experimenting with (source provided as link/attachment at bottom of this comment).

Things I did (to feed back in as potentially useful ideas):

• Two panels: List of agents on left. Selecting item in list displays corresponding debugger info
• Selecting agent in list, also sets the focus in Hierarchy using Selection.activeGameObject = ... (i.e. selecting an agent in the debugger list, also visibly selects the agent in the Scene view)
• Minor cosmetic text tweeks that I thought helped make it clearer to view (see screenshot)

AIDebuggerCustomEditor.cs.txt